1. The Field of the Invention
The present invention relates to systems and methods for translating delivery status notification information when messages are transferred from one type of network to another. More specifically, the present invention relates to systems and methods that translate delivery status notification information in such a manner that when a message transits from one network to another and then back again, the delivery status notification information on the returned message is the same as the original message.
2. Prior State of the Art
Although computers were once isolated and had minimal or little interaction with other computers, computers today interact with a wide variety of other computers through Local Area Networks (LANs), Wide Area Networks (WANs), dial-up connections, and so forth. With the wide-spread growth of the Internet, connectivity between computers is becoming more important and has opened up many new applications and technologies completely unthought of just a few short years ago. The growth of large scale networks and the widespread availability of low-cost personal computers has fundamentally changed the way that many people work, interact, communicate, and play.
Electronic communications among users of various computer systems have been known for many years. Many companies have developed internal electronic mail systems that allow email commnunication between various computers connected to corporate LANs or other networks. Many companies have reengineered their procedures and processes to take maximum advantage of email communications in order to provide a convenient mechanism for exchanging information and documents, thus reducing the handling of paperwork and speeding the flow of information between and among employees of various departments. With the advent of widespread connectivity offered by the Internet and the availability of email communications over the Internet, many companies are expanding the scope of email communications and connecting internal corporate LANs to the Internet or other wide area networks so that electronic communications can flow between various departments or divisions, clients, customers, employees, and others separated by large distances.
One mechanism to connect one network, such as a LAN, to another network, such as the Internet or other WAN, is to provide a gateway between the two networks. The gateway typically functions as an intermediary which takes messages or packets from one network and performs any protocol or other translations required to allow the message to flow through to the other network. As is expected, when email messages or other communications pass from one type of network to another there is often not a direct correlation between the features, protocols, and other information supported by the two networks. Thus, moving an email message from one type of network to another may require some translation or modification of certain information in the email message. Such modifications or translations are typically not required for the content of the message but, rather, involve other information carried along with the email message to provide information or features for delivery of the message.
As one example of information that may need translation, many networks support the basic concept of delivery status notification. Delivery status notification is sometimes referred to as a delivery receipt. Delivery status notification is intended to provide some feedback regarding the ultimate status of the delivery of the email message. For example, a sender of an email message may desire notification when the email message is delivered to its intended destination. As another example, the sender of an email message may desire notification if the message was never delivered or if delivery was somehow delayed beyond a certain point.
Because of the various standards supported by different networks, when email messages flow between networks there is often not a direct correlation between the types of delivery status notification options supported by different types of networks. As a simple example, the widespread pervasiveness of the Internet has convinced many of the importance of having access to, or transferring information over, the Internet. However, until recently no standard existed which specified what or how delivery status notification information was added or supported by the SMTP protocol used by the Internet. This changed with the promulgation of RFC 1891 which defines an extension to the SMTP protocol which allows an SMTP client to specify various delivery status notifications. For example, under RFC 1891 a client can specify that delivery status notification should be generated under certain conditions, whether such notifications should return the content of the message, and additional information, which is to be returned with a delivery status notification, that allows the sender to identify both the recipient for which the delivery status notification was issued, and the transaction in which the original message was sent. Thus, when connecting a non-SMTP networks to the Internet or other SMTP network, care must be taken to properly address how the delivery status notification options supported by the SMTP network are translated and handled when messages flow into or out of the non-SMTP network.
When transferring a message from one network to another, it is often common practice to attempt to preserve, as far as possible, the original sending options of the message. Thus, when a message having delivery status notification information passes from an SMTP network into a non-SMTP network, it is often desirable to translate the delivery status notification information into the closest option supported by the non-SMTP network. Such a translation process, however, invariably leads to data loss. For example, RFC 1891 specifies delivery status notification that is returned when delivery is delayed. X.400-based networks, however, have no concept of delivery status notification for delayed delivery. Many implementations of components that connect one type of network to another simply map the components to the closest available options and ignore information that cannot be mapped. This approach, however, can create unexpected problems.
As an example of the problems that may arise when information from one network is mapped into the closest available option and unmappable information is ignored may be illustrated by considering what happens to a message that passes from an SMTP network into a non-SMTP network and then passes back into the SMTP network. If the original message had delivery status notification information that requested notification when delivery was delayed, when the message passed into an X.400 network this information would be stripped and lost. If the message then subsequently returned to an SMTP network where option was supported, no such notification would be generated. It would, therefore, be highly desirable to implement mechanisms that restored all delivery status notification information to a message that passed into a foreign network and then returned from the foreign network back into the originating network. It would also be desirable to provide systems and methods that allowed such restoration to take place in a manner where the original message and the restored message where indistinguishable when examining the restored characteristics.